Digital press print engines are designed for long runs of printing where stopping and starting are infrequent. As such any page description language (PDL) rendering system must be able to keep pace with the speed of the printer engine. In a worst case situation, if there is a data underflow, paper is wasted while the printer slows down to stop and speeds up again on re-start as well as time lost while the engine is not printing.
Two typical approaches exist which try to address these requirements in PDL rendering for high-speed digital presses. One approach is to pre-raster image process (RIP) all of the PDL data off-line in order to deliver pixels to the printer engine at the target data rate. However this approach requires a lot of bandwidth in the input/output (IO) subsystem and network interconnections. Consider a colour digital press capable of the equivalent of 2000 A4 pages per minute (PPM) at 1200 dots per inch (DPI). If the colour image data is 8-bit per channel and with 4-colour channels, then each rendered A4 page is 533 MB in size. At an engine speed of 2000 pages per minute (PPM), that is 17 GB/s of data.
Moving large amounts of data quickly requires expensive high-speed buses. Another option is to use high-performance parallel rendering hardware and large in-memory frame stores in order to render page data and deliver pixels in real time to the printer engine. This approach is also not without its problems as render times for PDL pages are highly variable depending on the complexity of the PDL page.
Given that the high-speed digital press requires data to be transmitted to multiple data channels in order to drive the parallel print heads, using parallelism in the rendering solution to overcome PDL render time variability is an obvious choice. The difficulty comes with implementing a system that will efficiently handle the data requirements in-parallel without saturating storage, network or memory and maintaining the pixel delivery to the printer engine.
Some newer approaches attempt to segment the PDL data and distribute this among multiple PDL RIPs in order to speed up processing. However these systems still rely on traditional PDL rendering which is highly unpredictable in the time taken to render and also requires additional resources such as fonts.
One approach is to pre-process the PDL data and sanitize the PDL data into something that will likely render in the time required. Alternatively a pre-flight check of the data can be done, whereby an offline RIP of the entire PDL job is run to identify pages in the job that do not meet the required render time. The job is then changed to make sure it renders in the time required. Both of these approaches often involve pre-rendering complex pages to device resolution images.
Another method segments an input print job for parallel rendering. This, however has some drawbacks. The intermediate job format used is essentially another PDL, which requires font resource stored elsewhere on the system. The font resources can be different for every job that needs to be rendered, resulting in multiple accesses to the storage where the resource is stored. In this case, the renderer which implements this method has to stop the rendering process, unload old font resources and load new font resources, then start rendering the new job. This will delay the print engine and result in reduced performance.
Yet another method partitions the print job depending on whether a single or multiple RIP is to be performed. The print job is then replicated and substitute RIP commands are appended that affect the processing of the PDL data. This approach results in a duplication of PDL data which is inefficient.